DEV: expose current program application in detail - #731

База

• Точный backend base SHA: 63ebc4accdb147cf1e02feaaf141d79e7d92966b (origin/dev после git fetch origin).

Зачем

Angular PR #339 должен различать состояния «Создать заявку» и «Перейти в заявку». Восстановление заявки через GET /auth/users/projects/ ненадежно: legacy serializers возвращают одну singular-связь partner_program, хотя один Project может быть связан с несколькими программами через PartnerProgramProject. Из-за этого для программы B могла выбираться более ранняя связь программы A.

Что изменено

• В существующий GET /programs/<id>/ добавлено стабильное top-level поле current_application.
• Новый endpoint не создавался.
• Для пользователя без заявки поле равно null.
• Для существующей заявки контракт:

  {
    "current_application": {
      "project_id": 123,
      "program_link_id": 700,
      "submitted": false
    }
  }

• Lookup строго program-scoped: partner_program_id=<current program> и project__leader_id=<current user>.
• Владельцем заявки считается только leader Project; collaborator чужого проекта не получает эту заявку.
• submitted берется напрямую из PartnerProgramProject.submitted.
• Multi-program regression фиксирует выбор связи запрошенной программы B, даже если связь A была создана раньше.
• При legacy-дубликатах детерминированно выбирается минимальный PartnerProgramProject.pk.
• Anonymous и authenticated non-member получают current_application: null; lookup заявки для них не выполняется.
• Для member detail добавляется не более одного constant SQL lookup через .values(...).first(), без pagination scan и N+1.
• Apply contract POST /programs/<id>/projects/apply/ не изменялся.
• Модели, migrations, dependencies, Docker и workflows не изменялись.

Regression-тесты

Добавлены сценарии:

1. anonymous → null;
2. authenticated non-member → null;
3. member без заявки → null;
4. draft application → object с submitted: false;
5. submitted link → submitted: true;
6. один Project в программах A и B → detail B возвращает link B;
7. проекты из другой программы не влияют на результат;
8. проект другого leader не раскрывается;
9. collaborator чужого проекта не считается владельцем;
10. legacy duplicate → минимальный link pk без MultipleObjectsReturned.

Проверки

Локально выполнены:

• Python 3.12 syntax compilation измененных Python-файлов;
• git diff --check;
• проверка scope: модели, migrations, dependency-файлы, Docker и workflows не изменены;
• merge-base с origin/dev подтвержден как 63ebc4accdb147cf1e02feaaf141d79e7d92966b.

Локально не выполнены и оставлены для CI:

• targeted Django suites (program detail/apply/welcome/submission/case fields/analytics);
• полный backend suite;
• Black;
• flake8;
• Django system checks;
• migration check;
• PostgreSQL suite.

Причина: в локальном окружении нет установленных backend dependencies, доступ к package index недоступен, а Docker daemon недоступен. Dependency-файлы и Docker/workflows намеренно не менялись.